This section is intended to introduce the reader to various aspects of art, which may be related to various aspects of the present invention that are described and/or claimed below. This discussion is believed to be helpful in providing the reader with background information to facilitate a better understanding of the various aspects of the present invention. Accordingly, it should be understood that these statements are to be read in this light, and not as admissions of prior art.
Adaptive streaming over HTTP (also called multi-bitrate switching or HAS) is quickly becoming a major technology for multimedia content distribution. Among the HTTP adaptive streaming protocols which are already used, the most famous are the HTTP Live Streaming (HLS) from Apple, the Silverlight Smooth Streaming (SSS) from Microsoft, the Adobe Dynamic Streaming (ADS) from Adobe, the Dynamic Adaptive Streaming over HTTP (DASH) developed by 3GPP and MPEG (standardized as ISO/IEC 23009-1:2012).
When a client terminal wishes to play an audiovisual content (or A/V content) in adaptive streaming, it first has to get a file describing how this A/V content might be obtained. This is generally done through the HTTP protocol by getting a description file, so-called manifest, from an URL (Uniform Resource Locator), but can be also achieved by other means (e.g. broadcast, e-mail, SMS and so on). The manifest—generated in advance and delivered to the client terminal by a remote server—basically lists the available representations (also called instances or versions) of such an A/V content (in terms of bitrate, resolution and other properties). A representation is associated with a given quality level (bitrate).
The whole data stream of each representation is divided into segments (also called chunks) of equal duration (accessible by a separate URL) which are made such that a client terminal may smoothly switch from one quality level to another between two segments. As a result, the video quality may vary while playing but rarely suffers from interruptions (also called freezes).
At the client side, the segments are selected based on a measure of the available bandwidth of the transmission path. In particular, a client terminal usually requests the representation of a segment corresponding to a bitrate encoding and thus a quality compliant with the measured bandwidth.
When a cache is along the transmission path between a client terminal and a remote server, one representation of a given segment may already be stored in said cache, in case another client has previously requested the same segment with the same representation or in case a Content Delivery Network (CDN) has already provisioned the segment in the cache. Thus, the response to an HTTP request for said given segment is faster than if the segment comes from the remote server and duplicate transmission can be avoided, effectively saving network and server resources.
Nevertheless, the HTTP adaptive streaming appears not to be cache friendly (or at least less cache friendly than the so called layered base switching as for instance H264-SVC). Indeed, if a first client terminal requests a representation R1 of a given segment and a second client terminal—sharing a part of the transmission path with said first client terminal and a cache—requests a representation R2 of said given segment (at a higher or lower quality), then the cache is not hit leading to higher load on the network segment between the cache and the server with the risk of causing congestion. The benefits of caching are then completely annihilated and caches are currently unable to improve this situation.
To overcome this shortcoming, it is known that a client terminal may send a request for a given segment comprising a first (also called preferred) representation and one or several alternative representations. When such a request arrives at an HAS aware cache (meaning that said cache is compliant with an HAS protocol, such as MPEG-DASH), said cache delivers the first representation if cached or browses the alternative representations in case the first representation is not cached. When one of the alternative representations is cached, the cache sends said alternative representation to the client terminal. When none of the first and alternative representations of the request is cached, the request is forwarded upstream.
However, the representations stored in the cache are determined by previous requests. If a first client terminal requests a segment with a representation R, subsequent client terminals—requesting the same segment and specifying the representation R as an alternative representation—will actually receive the representation R rather than the first (or preferred) representation of the corresponding request. Since the requests of the subsequent client terminals are considered handled by the cache, other representations of the segment will not be loaded into the cache (unless some client terminals request for a first representation, not cached, without allowing R as an alternative representation). If the representation R is a low quality representation (for instance because the first client terminal starting the request for a given segment undergoes poor network conditions for itself and requests the lowest quality representation), all or a majority of client terminals may play a low quality video while resources and network conditions may allow to deal with a higher quality.
Thus, the first client terminal to request a given segment may influence the response (and then the quality) provided by the cache to the subsequent client terminals requesting the same segment. As a consequence, if the first client terminal is unfortunately not representative of the needs of the majority of client terminals, said majority of terminals will suffer from the request and behavior of the first client terminal.
The present invention overcomes at least the above mentioned shortcomings.